home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1468 < prev    next >
Text File  |  1995-07-25  |  11KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           J. Murai
  8. Request for Comments: 1468                               Keio University
  9.                                                               M. Crispin
  10.                                                        Panda Programming
  11.                                                          E. van der Poel
  12.                                                                June 1993
  13.  
  14.  
  15.            Japanese Character Encoding for Internet Messages
  16.  
  17. Status of this Memo
  18.  
  19.    This memo provides information for the Internet community.  It does
  20.    not specify an Internet standard.  Distribution of this memo is
  21.    unlimited.
  22.  
  23. Introduction
  24.  
  25.    This document describes the encoding used in electronic mail [RFC822]
  26.    and network news [RFC1036] messages in several Japanese networks. It
  27.    was first specified by and used in JUNET [JUNET]. The encoding is now
  28.    also widely used in Japanese IP communities.
  29.  
  30.    The name given to this encoding is "ISO-2022-JP", which is intended
  31.    to be used in the "charset" parameter field of MIME headers (see
  32.    [MIME1] and [MIME2]).
  33.  
  34. Description
  35.  
  36.    The text starts in ASCII [ASCII], and switches to Japanese characters
  37.    through an escape sequence. For example, the escape sequence ESC $ B
  38.    (three bytes, hexadecimal values: 1B 24 42) indicates that the bytes
  39.    following this escape sequence are Japanese characters, which are
  40.    encoded in two bytes each.  To switch back to ASCII, the escape
  41.    sequence ESC ( B is used.
  42.  
  43.    The following table gives the escape sequences and the character sets
  44.    used in ISO-2022-JP messages. The ISOREG number is the registration
  45.    number in ISO's registry [ISOREG].
  46.  
  47.        Esc Seq    Character Set                  ISOREG
  48.  
  49.        ESC ( B    ASCII                             6
  50.        ESC ( J    JIS X 0201-1976 ("Roman" set)    14
  51.        ESC $ @    JIS X 0208-1978                  42
  52.        ESC $ B    JIS X 0208-1983                  87
  53.  
  54.    Note that JIS X 0208 was called JIS C 6226 until the name was changed
  55.  
  56.  
  57.  
  58. Murai, Crispin & van der Poel                                   [Page 1]
  59.  
  60. RFC 1468   Japanese Character Encoding for Internet Messages   June 1993
  61.  
  62.  
  63.    on March 1st, 1987. Likewise, JIS C 6220 was renamed JIS X 0201.
  64.  
  65.    The "Roman" character set of JIS X 0201 [JISX0201] is identical to
  66.    ASCII except for backslash () and tilde (~). The backslash is
  67.    replaced by the Yen sign, and the tilde is replaced by overline. This
  68.    set is Japan's national variant of ISO 646 [ISO646].
  69.  
  70.    The JIS X 0208 [JISX0208] character sets consist of Kanji, Hiragana,
  71.    Katakana and some other symbols and characters. Each character takes
  72.    up two bytes.
  73.  
  74.    For further details about the JIS Japanese national character set
  75.    standards, refer to [JISX0201] and [JISX0208].  For further
  76.    information about the escape sequences, see [ISO2022] and [ISOREG].
  77.  
  78.    If there are JIS X 0208 characters on a line, there must be a switch
  79.    to ASCII or to the "Roman" set of JIS X 0201 before the end of the
  80.    line (i.e., before the CRLF). This means that the next line starts in
  81.    the character set that was switched to before the end of the previous
  82.    line.
  83.  
  84.    Also, the text must end in ASCII.
  85.  
  86.    Other restrictions are given in the Formal Syntax below.
  87.  
  88. Formal Syntax
  89.  
  90.    The notational conventions used here are identical to those used in
  91.    RFC 822 [RFC822].
  92.  
  93.    The * (asterisk) convention is as follows:
  94.  
  95.        l*m something
  96.  
  97.    meaning at least l and at most m somethings, with l and m taking
  98.    default values of 0 and infinity, respectively.
  99.  
  100.  
  101.    message             = headers 1*( CRLF *single-byte-char *segment
  102.                          single-byte-seq *single-byte-char )
  103.                                            ; see also [MIME1] "body-part"
  104.                                            ; note: must end in ASCII
  105.  
  106.    headers             = <see [RFC822] "fields" and [MIME1] "body-part">
  107.  
  108.    segment             = single-byte-segment / double-byte-segment
  109.  
  110.    single-byte-segment = single-byte-seq 1*single-byte-char
  111.  
  112.  
  113.  
  114. Murai, Crispin & van der Poel                                   [Page 2]
  115.  
  116. RFC 1468   Japanese Character Encoding for Internet Messages   June 1993
  117.  
  118.  
  119.    double-byte-segment = double-byte-seq 1*( one-of-94 one-of-94 )
  120.  
  121.    single-byte-seq     = ESC "(" ( "B" / "J" )
  122.  
  123.    double-byte-seq     = ESC "$" ( "@" / "B" )
  124.  
  125.    CRLF                = CR LF
  126.  
  127.                                                     ; ( Octal, Decimal.)
  128.  
  129.    ESC                 = <ISO 2022 ESC, escape>     ; (    33,      27.)
  130.  
  131.    SI                  = <ISO 2022 SI, shift-in>    ; (    17,      15.)
  132.  
  133.    SO                  = <ISO 2022 SO, shift-out>   ; (    16,      14.)
  134.  
  135.    CR                  = <ASCII CR, carriage return>; (    15,      13.)
  136.  
  137.    LF                  = <ASCII LF, linefeed>       ; (    12,      10.)
  138.  
  139.    one-of-94           = <any one of 94 values>     ; (41-176, 33.-126.)
  140.  
  141.    7BIT                = <any 7-bit value>          ; ( 0-177,  0.-127.)
  142.  
  143.    single-byte-char    = <any 7BIT, including bare CR & bare LF, but NOT
  144.                           including CRLF, and not including ESC, SI, SO>
  145.  
  146. MIME Considerations
  147.  
  148.    The name given to the JUNET character encoding is "ISO-2022-JP". This
  149.    name is intended to be used in MIME messages as follows:
  150.  
  151.        Content-Type: text/plain; charset=iso-2022-jp
  152.  
  153.    The ISO-2022-JP encoding is already in 7-bit form, so it is not
  154.    necessary to use a Content-Transfer-Encoding header. It should be
  155.    noted that applying the Base64 or Quoted-Printable encoding will
  156.    render the message unreadable in current JUNET software.
  157.  
  158.    ISO-2022-JP may also be used in MIME Part 2 headers.  The "B"
  159.    encoding should be used with ISO-2022-JP text.
  160.  
  161. Background Information
  162.  
  163.    The JUNET encoding was described in the JUNET User's Guide [JUNET]
  164.    (JUNET Riyou No Tebiki Dai Ippan).
  165.  
  166.    The encoding is based on the particular usage of ISO 2022 announced
  167.  
  168.  
  169.  
  170. Murai, Crispin & van der Poel                                   [Page 3]
  171.  
  172. RFC 1468   Japanese Character Encoding for Internet Messages   June 1993
  173.  
  174.  
  175.    by 4/1 (see [ISO2022] for details). However, the escape sequence
  176.    normally used for this announcement is not included in ISO-2022-JP
  177.    messages.
  178.  
  179.    The Kana set of JIS X 0201 is not used in ISO-2022-JP messages.
  180.  
  181.    In the past, some systems erroneously used the escape sequence ESC (
  182.    H in JUNET messages. This escape sequence is officially registered
  183.    for a Swedish character set [ISOREG], and should not be used in ISO-
  184.    2022-JP messages.
  185.  
  186.    Some systems do not distinguish between ESC ( B and ESC ( J or
  187.    between ESC $ @ and ESC $ B for display. However, when relaying a
  188.    message to another system, the escape sequences must not be altered
  189.    in any way.
  190.  
  191.    The human user (not implementor) should try to keep lines within 80
  192.    display columns, or, preferably, within 75 (or so) columns, to allow
  193.    insertion of ">" at the beginning of each line in excerpts. Each JIS
  194.    X 0208 character takes up two columns, and the escape sequences do
  195.    not take up any columns. The implementor is reminded that JIS X 0208
  196.    characters take up two bytes and should not be split in the middle to
  197.    break lines for displaying, etc.
  198.  
  199.    The JIS X 0208 standard was revised in 1990, to add two characters at
  200.    the end of the table. Although ISO 2022 specifies special additional
  201.    escape sequences to indicate the use of revised character sets, it is
  202.    suggested here not to make use of this special escape sequence in
  203.    ISO-2022-JP text, even if the two characters added to JIS X 0208 in
  204.    1990 are used.
  205.  
  206.    For further information about Japanese character encodings such as PC
  207.    codes, FTP locations of implementations, etc, see "Electronic
  208.    Handling of Japanese Text" [JPN.INF].
  209.  
  210. References
  211.  
  212.    [ASCII] American National Standards Institute, "Coded character set
  213.    -- 7-bit American national standard code for information
  214.    interchange", ANSI X3.4-1986.
  215.  
  216.    [ISO646] International Organization for Standardization (ISO),
  217.    "Information technology -- ISO 7-bit coded character set for
  218.    information interchange", International Standard, Ref. No. ISO/IEC
  219.    646:1991.
  220.  
  221.    [ISO2022] International Organization for Standardization (ISO),
  222.    "Information processing -- ISO 7-bit and 8-bit coded character sets
  223.  
  224.  
  225.  
  226. Murai, Crispin & van der Poel                                   [Page 4]
  227.  
  228. RFC 1468   Japanese Character Encoding for Internet Messages   June 1993
  229.  
  230.  
  231.    -- Code extension techniques", International Standard, Ref. No. ISO
  232.    2022-1986 (E).
  233.  
  234.    [ISOREG] International Organization for Standardization (ISO),
  235.    "International Register of Coded Character Sets To Be Used With
  236.    Escape Sequences".
  237.  
  238.    [JISX0201] Japanese Standards Association, "Code for Information
  239.    Interchange", JIS X 0201-1976.
  240.  
  241.    [JISX0208] Japanese Standards Association, "Code of the Japanese
  242.    graphic character set for information interchange", JIS X 0208-1978,
  243.    -1983 and -1990.
  244.  
  245.    [JPN.INF] Ken R. Lunde <lunde@adobe.com>, "Electronic Handling of
  246.    Japanese Text", March 1992,
  247.    msi.umn.edu(128.101.24.1):pub/lunde/japan[123].inf
  248.  
  249.    [JUNET] JUNET Riyou No Tebiki Sakusei Iin Kai (JUNET User's Guide
  250.    Drafting Committee), "JUNET Riyou No Tebiki (Dai Ippan)" ("JUNET
  251.    User's Guide (First Edition)"), February 1988.
  252.  
  253.    [MIME1] Borenstein N., and N. Freed, "MIME (Multipurpose
  254.    Internet Mail Extensions): Mechanisms for Specifying and
  255.    Describing the Format of Internet Message Bodies", RFC 1341,
  256.    Bellcore, Innosoft, June 1992.
  257.  
  258.    [MIME2] Moore, K., "Representation of Non-ASCII Text in Internet
  259.    Message Headers", RFC 1342, University of Tennessee, June 1992.
  260.  
  261.    [RFC822] Crocker, D., "Standard for the Format of ARPA Internet
  262.    Text Messages", STD 11, RFC 822, UDEL, August 1982.
  263.  
  264.    [RFC1036] Horton M., and R. Adams, "Standard for Interchange of USENET
  265.    Messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic
  266.    Studies, December 1987.
  267.  
  268. Acknowledgements
  269.  
  270.    Many people assisted in drafting this document. The authors wish to
  271.    thank in particular Akira Kato, Masahiro Sekiguchi and Ken'ichi
  272.    Handa.
  273.  
  274. Security Considerations
  275.  
  276.    Security issues are not discussed in this memo.
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Murai, Crispin & van der Poel                                   [Page 5]
  283.  
  284. RFC 1468   Japanese Character Encoding for Internet Messages   June 1993
  285.  
  286.  
  287. Authors' Addresses
  288.  
  289.    Jun Murai
  290.    Keio University
  291.    5322 Endo, Fujisawa
  292.    Kanagawa 252 Japan
  293.  
  294.    Fax: +81 466 49 1101
  295.    EMail: jun@wide.ad.jp
  296.  
  297.  
  298.    Mark Crispin
  299.    Panda Programming
  300.    6158 Lariat Loop NE
  301.    Bainbridge Island, WA 98110-2098
  302.    USA
  303.  
  304.    Phone: +1 206 842 2385
  305.    EMail: MRC@PANDA.COM
  306.  
  307.  
  308.    Erik M. van der Poel
  309.    A-105 Park Avenue
  310.    4-4-10 Ohta, Kisarazu
  311.    Chiba 292 Japan
  312.  
  313.    Phone: +81 438 22 5836
  314.    Fax:   +81 438 22 5837
  315.    EMail: erik@poel.juice.or.jp
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Murai, Crispin & van der Poel                                   [Page 6]
  339.  
  340.